home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / snmpv2 / 92nov.min next >
Text File  |  1993-02-17  |  18KB  |  475 lines

  1. Editor's Note: Minutes received 12/9/92
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5. Reported by Marshall Rose/DBC
  6.  
  7. Minutes of the SNMP Version 2 Working Group (SNMPV2)
  8.  
  9. The Agenda was reviewed and approved.  In the discussion which follows,
  10. the decisions reached by the Working Group are summarized.  In the
  11. majority of cases, there was significant, protracted discussion.  In the
  12. interests of brevity, that discussion is not reproduced here.
  13.  
  14. Outstanding Procedural Issues were Discussed
  15.  
  16.  
  17.    o Deadline to Finish:  Although a meeting slot has been identified
  18.      for December, the Chair wanted to try to conclude business this
  19.      week as several slots were scheduled for the Working Group.  There
  20.      was strong consensus that an additional meeting should be avoided
  21.      if at all possible.
  22.  
  23.    o No New Proposals:  There was consensus that only ``bug fixes'' and
  24.      ``show stoppers'' would be addressed after the conclusion of this
  25.      meeting.  The one exception is the row-creation and associated
  26.      proposals, see III.10 below.
  27.  
  28.    o Deadlock Shelf:  There was consensus that deadlock shelf would
  29.      remain in place for proposals for which consensus could not be
  30.      reached.  From time to time, these items will be taken off the
  31.      shelf to see if there is a new consensus.
  32.  
  33.    o More Implementation Experience:  There was consensus that no
  34.      additional implementation requirements would be placed on the
  35.      documents prior to the Working Group completing its work.
  36.  
  37.  
  38. Deadlock Shelf:
  39.  
  40. 1.  Changing descriptors/enumerations w/o changing object's OID
  41.  
  42. There was consensus that this would not be allowed, because descriptors
  43. could be IMPORTed to other modules.  As such, a change in either would
  44. result in a change in OID.
  45.  
  46. 2.  Adding enumerations w/o changing object's OID
  47.  
  48. An action was taken by the editor and Dave Perkins to make a proposal in
  49. this area.  After discussion, the proposal was rejected and instead
  50. there was consensus that adding enumerations w/o changing an object's
  51. OID was permissible.
  52.  
  53. 3.  LABEL clause
  54.  
  55.                                    1
  56.  
  57.  
  58.  
  59.  
  60.  
  61. There was consensus that this clause was to be dropped.  However, a new
  62. effort outside of the SNMPv2 Working Group should be formed to
  63. investigate related functionality outside of the OBJECT-TYPE macro.
  64.  
  65. 4.  Accessibilities of auxiliary objects
  66.  
  67. There was considerable deadlock and intransigence on this issue.
  68. Finally, it was observed that the two camps had polarized into agent
  69. implementors (not-accessible) and management station implementors
  70. (read-only), so the chair decided the issue in favor of the agent
  71. implementors:  not-accessible was selected.
  72.  
  73. 5.  readOnly error-status
  74.  
  75. Since some implementations return this value, the PROTO and COEX
  76. documents were updated to reflect this and indicate the appropriate
  77. actions to take.
  78.  
  79. 6.  RowStatus:  a SHOULD or MUST
  80.  
  81. No consensus was reached as Marshall Rose argued the absent Karl's
  82. Auerbach's position.  As such, the current text, ``should'' remains.
  83.  
  84. III. New proposals:
  85.  
  86. In order to facilitate the discussion, each presenter was required to
  87. first demonstrate a problem, before presenting a solution.
  88.  
  89. 1.  Tracy Cox of Bellcore demonstrated that delayed operations (e.g.,
  90. due to slow proxy) was a problem.  Discussion of solutions was tabled
  91. until after the SNMP Security WG meeting later that evening.  At that
  92. meeting, two proposals were suggested.  As such, this issue has been
  93. moved to the SNMP Security WG.
  94.  
  95. 2.  Dave Arneson of Cabletron suggested that efficient retrieval of
  96. tabular objects was a problem.  There was consensus that, in
  97. bandwidth-limited environments, retrieval should be more efficient.
  98. However, there was no consensus that this problem was specific to
  99. tables.
  100.  
  101. 3.  Anil Rijsinghani of DEC was absent, but a colleague demonstrated
  102. that auto-discovery of SNMP agents was a problem.  There was consensus
  103. that the proposal was on the right track, but that this work could
  104. proceed independently from the SNMPv2 effort.
  105.  
  106. 4.  Dave Perkins of SynOptics suggested that retrieval of
  107. non-rectangular tables was a problem and there was sufficient interest
  108. to look at the solution.  However, there was consensus that there wasn't
  109. enough of a problem to warrant the solution.
  110.  
  111. 5.  Dave Perkins of SynOptics presented his 41 SMI issues.  A few of
  112. these were postponed to an off-line editing meeting (see Section IV
  113. below).  Although all of the issues were discussed, in the interests of
  114. brevity, only those issues which led to a change in the document are
  115.  
  116.                                    2
  117.  
  118.  
  119.  
  120.  
  121.  
  122. presented:
  123.  
  124. - Module labels, e.g., ``FOO'' in ``FOO DEFINITIONS ::= BEGIN'' must not
  125. change across revisions of an information module.
  126.  
  127. - The module revision procedures didn't indicate how to revise
  128. invocations of the OBJECT-GROUP macro.
  129.  
  130. - The introductory text for each document will be normalized.
  131.  
  132. - An action was taken by Jeff Case to provide an (approximately two
  133. page) introduction to the components in the network management system
  134. and their relationship.
  135.  
  136. - Parts of the SMI were re-ordered for ease of reading.
  137.  
  138. - The MODULE-COMPLIANCE and AGENT-CAPABILITIES macros were moved to a
  139. new document, ``CONF''.
  140.  
  141. - An unsigned 32-bit integer-valued tagged type was defined.
  142.  
  143. - Full ASN.1 sub-typing, appropriate to the ASN.1 type being refined, is
  144. allowed.  (This is a clarification.)
  145.  
  146. - The OID-VAL macro for registration assignments was created, but the
  147. editor changed the name to OBJECT-IDENTITY.
  148.  
  149. - Text noting that the tagged types for IpAddress and NsapAddress were
  150. historical was added.
  151.  
  152. - Clarifications of the AUGMENTS clause were made.
  153.  
  154. - Missing SMI-level coexistence issues were codified.
  155.  
  156. 6.  Sam Roberts of Farallon presented his SMI issues.
  157.  
  158. - Various ASN.1 grammar typos in the macro were corrected.
  159.  
  160. - Clarifying text indicating that Counters can not, but that Gauges can
  161. be sub-typed was added.
  162.  
  163. - Hyphens are not allowed in descriptor labels, enumerated labels, or
  164. the names of textual conventions.  (This used to be a requirement ONLY
  165. for ``standard'' MIBs, now all MIBs must obey this rule.)  The COEX
  166. document indicates that these changes may be made without deprecating
  167. objects.
  168.  
  169. - Problems with the IMPLIED clause were identified and a solution
  170. provided.
  171.  
  172. 7.  Anil Rijsinghani of DEC was absent, but a Jon Saperia discussed a
  173. need for a unsigned 64-bit type.  However, the Group could not achieve
  174. consensus on any adequate choke rule.  As such, following there was
  175. consensus that despite some usefulness, that such a type would not be
  176.  
  177.                                    3
  178.  
  179.  
  180.  
  181.  
  182.  
  183. added.
  184.  
  185. 8.  Marshall Rose of DBC described a problem in the definition of the
  186. TEXTUAL-CONVENTION macro along with a solution.  Textual conventions are
  187. now written as
  188.  
  189. <name> ::= TEXTUAL-CONVENTION <clauses ...> SYNTAX <syntax>
  190.  
  191. This is necessary due to macro definition restrictions in ASN.1
  192.  
  193. 9.  Jeff Case of UTK suggested that the limitations on enumerated values
  194. in INTEGERs was causing problems when translating MIBs written by other
  195. groups.  There was consensus that the limitations should be removed with
  196. a recommendation that newly defined objects follow the old rules.
  197.  
  198. 10.  Bill Norton of Merit presented the row-creation portion of the
  199. multi-part proposal by Guenther Schreiner, et.  al.  Discussion lasted
  200. for over two hours.
  201.  
  202. Group consensus was that Create/Delete operators were not the solution
  203. to row creation, but there is a problem with complexity and multiple
  204. ways to use RowStatus.  Jeff Case took an action to reconsider this
  205. problem.  The chair set a deadline of 12/4 for final resolution on this
  206. issue and consideration of the other proposals that came with this one.
  207.  
  208. In comparing the row-creation proposal to the RowStatus mechanism, it
  209. was agreed that the row-creation proposal did not solve the general
  210. problem of row creation, as:  1.  Sometimes multiple PDU exchanges were
  211. necessary in order to create a row, e.g., either because of a resource
  212. negotiation process between the agent and manager, or because there
  213. might be too much data to fit in a single creation request.  2.  The
  214. response from the creation PDU added varbinds in order to indicate what
  215. mandatory columns are missing.  However, this could make the request too
  216. big to send back.  3.  The creation request is not idempotent due to
  217. potential packet duplication and loss from the underlying transport
  218. service (i.e., the request gets duplicated, the first succeeds, but the
  219. response is lost, the second fails, and its response is returned.)
  220.  
  221. It was also observed that with the RowStatus mechanism, creation could
  222. be done in a single exchange, if the DEFVAL clause was active and the
  223. manager did a set to active.  However, it was agreed that this text
  224. should be made more clear.  An action was taken by Steve Waldbusser.
  225.  
  226. After much discussion, there was consensus that the real problem was
  227. that the community had three requirements:  1.  A single, consistent way
  228. to do row-creation.  2.  Some row-creations take more than 1 exchange.
  229. 3.  Some agent writers wish to implement a simple table in such a way so
  230. that row creation must be done in a single exchange.
  231.  
  232. An action was taken by Jeff Case on behalf of the four SMP authors to
  233. see if some solution could be found which had these properties:  1.
  234. Avoided the tooBig problem.  2.  Dealt with the discovery problem of
  235. missing columns and defvals.  3.  Avoided stateful behavior.  Jeff Case
  236. was careful to stress that this issue had been look at, in great detail
  237.  
  238.                                    4
  239.  
  240.  
  241.  
  242.  
  243.  
  244. by the SMP authors prior to the publication of the SMP specification,
  245. and he was doubtful that a solution could be found.
  246.  
  247. IV. Off-line editing:
  248.  
  249. With the approval of the Working Group, Dave Perkins met with the editor
  250. to deal with numerous minor issues:
  251.  
  252. - Because groups deal with both conformance and naming, the OBJECT-GROUP
  253. macro was moved to the new CONF document to be used for conformance
  254. purposes, and the SMI (and MIB and M2M) documents use the SNMPv1
  255. mechanism for naming object groups.
  256.  
  257. - A usage example was clarified.
  258.  
  259. - The intention of textual conventions was clarified.
  260.  
  261. - It was redundantly noted that Counter objects do not have DEFVAL
  262. clauses.
  263.  
  264. - An example of ``epoch'' was given for TimeTicks.
  265.  
  266. - The text concerning Opaque type was stream-lined.
  267.  
  268. - The use of the experimental branch was aligned with reality.
  269.  
  270. - When the STATUS clause of an object changes, its DESCRIPTION clause
  271. should be updated accordingly.
  272.  
  273. V. Actions Outstanding:
  274.  
  275. - Jeff Case:  introductory text
  276.  
  277. - Steve Waldbusser:  look at clarifying RowStatus/DEFVAL active text.
  278.  
  279. - Four authors:  look at row-creation issues
  280.  
  281. - WG: discuss and resolve the Schreiner, et.  al.  proposals on
  282. Set2Default, short termination of get-bulk, etc.
  283.  
  284. VI. Timetable:
  285.  
  286. There was strong consensus that the row-creation issue and other
  287. associated, unresolved proposals.  would be given until Friday, December
  288. 4 to achieve resolution.
  289.  
  290. There was *complete* consensus that the final deadline for comments on
  291. the 9 SNMPv2 documents would be
  292.  
  293. Friday, December 11
  294.  
  295. Unless the SNMP Security effort raised new issues, then the documents
  296. would be sent forward to the IESG with a recommendation for advancement
  297. to the standards-track from the Working Group.
  298.  
  299.                                    5
  300.  
  301.  
  302.  
  303.  
  304.  
  305. Finally, it was observed that the SNMPv2 documents could not go forward
  306. without the revisions the 3 SNMP Security documents.  As such, it was
  307. suggested that the membership of the SNMPv2 Working Group now focus its
  308. energies on the issues before the SNMP Security Working Group.
  309.  
  310. VII. Documents:
  311.  
  312. Revised versions of the SNMPv2 documents were submitted to the
  313. Internet-Drafts area.  In addition, ``unofficial'' copies are available
  314. via anonymous ftp:
  315.  
  316. host ftp.ics.uci.edu area mrose/snmpv2/ files *.txt
  317.  
  318. The documents can also be retrieved via e-mail:
  319.  
  320. mailbox archive-server@ftp.ics.uci.edu body MIMESEND
  321. mrose/mh-mime/snmpv2
  322.  
  323. These documents will be removed once the actual Internet-Drafts are announced.
  324.  
  325. Attendees
  326.  
  327. Elizabeth Adams          adamse@attmail.com
  328. Steve Alexander          stevea@i88.isc.com
  329. David Arneson            arneson@ctron.com
  330. Toshiya Asaba            asaba@wide.sfc.keio.ac.jp
  331. Fred Baker               fbaker@acc.com
  332. Jim Barnes               barnes@xylogics.com
  333. Brian Bataille           bataillebc@afotec.af.mil
  334. Andy Bierman             abierman@synoptics.com
  335. Fred Bohle               fab@interlink.com
  336. Jack Brown               jbrown@huachuca-emh8.army.mil
  337. Theodore Brunner         tob@thumper.bellcore.com
  338. Stephen Bush             sfb@ncoast.org
  339. Jeff Case                case@cs.utk.edu
  340. John Chang               changj@ralvm6.vnet.ibm.com
  341. Szusin Chen              szusin.chen@eng.sun.com
  342. Robert Ching             rching@nat.com
  343. Chris Chiotasso          chris@andr.ub.com
  344. Bobby Clay               clay@eagle.msfc.nasa.gov
  345. John Cook                cook@chipcom.com
  346. Tracy Cox                tacox@sabre.bellcore.com
  347. Juan Cruz                juan@dss.com
  348. Dave Cullerot            cullerot@ctron.com
  349. Cathy Cunningham         cmc@microcom.com
  350. James Davin              davin@bellcore.com
  351. Michael Davis            mad@spirit.clearpoint.com
  352. Michael Davison          davison@fibercom.com
  353. Cynthia Della Torre      cindy@gateway.mitre.org
  354. Manuel Diaz              diaz@davidsys.com
  355. Jon Dreyer               Jon.Dreyer@east.sun.com
  356. Jacques Dugast           dugast@issy.cnet.fr
  357. Donald Eastlake          dee@ranger.enet.dec.com
  358.  
  359.                                    6
  360.  
  361.  
  362.  
  363.  
  364.  
  365. David Engel              david@ods.com
  366. Michael Erlinger         mike@jarthur.claremont.edu
  367. Roger Fajman             raf@cu.nih.gov
  368. Daniel Fauvarque         dfauvarq@france.sun.com
  369. Karen Frisa              karen.frisa@andrew.cmu.edu
  370. Shari Galitzer           shari@mitre.org
  371. Shawn Gallagher          gallagher@quiver.enet.dec.com
  372. Richard Graveman         rfg@ctt.bellcore.com
  373. Maria Greene             mngreene@eng.xyplex.com
  374. Michel Guittet           guittet1@applelink.apple.com
  375. Robert Gutierrez         gutierre@nsipo.nasa.gov
  376. William Haggerty         haggerty@ctron.com
  377. Patrick Hanel            hanel@yoyodyne.dco.ntc.nokia.com
  378. Ed Heiner                eah@pau.synnet.com
  379. Gerd Holzhauer           holzhauer1@applelink.apple.com
  380. John Hopprich            hopprich@davidsys.com
  381. Jeff Hughes              jeff@col.hp.com
  382. David Husak              dave@synnet.com
  383. Robin Iddon              robini@cix.compulink.co.uk
  384. Kevin Jackson            kmj@concord.com
  385. Ole Jacobsen             ole@interop.com
  386. Ronald Jacoby            rj@sgi.com
  387. Frank Kastenholz         kasten@ftp.com
  388. Mark Kepke               mak@cnd.hp.com
  389. Zbigniew Kielczewski     zbig@eicon.qc.ca
  390. Jong Yeol Kim            kimjy@ring.kotel.co.kr
  391. Andrew Knutsen           andrewk@sco.com
  392. Michael Kornegay         mlk@bir.com
  393. Deirdre Kostick          dck2@sabre.bellcore.com
  394. Michael Laufer           mlaufer@bbn.com
  395. Mark Lewis               mlewis@telebit.com
  396. David Lin                lind@janus-ccm.zenith.com
  397. David Lindemulder        dcl@mtung.att.com
  398. Benjamin Lisowski        Ben.Lisowski@sprint.sprint.com
  399. David Liu                dliu@bnr.ca
  400. John Lunny               jlunny@twg.com
  401. Carl Madison             carl@startek.com
  402. Keith McCloghrie         kzm@hls.com
  403. Evan McGinnis            bem@3com.com
  404. William McKenzie         mckenzie@ralvma.vnet.ibm.com
  405. Donna McMaster           mcmaster@synoptics.com
  406. John Medicke             medicke@ralvm11.vnet.ibm.com
  407. Douglas Miller           dmm@telebit.com
  408. David Minnich            dwm@fibercom.com
  409. Mohammad Mirhakkak       mmirhakk@mitre.org
  410. Rohit Mital              rm@protools.com
  411. George Mouradian         gvm@arch3.att.com
  412. Patrick Mullaney         mullaney@ctron.com
  413. Daniel Myers             dan@nsd.3com.com
  414. Rina Nathaniel           rina!rnd!rndi@uunet.uu.net
  415. Hien Nguyen              h.nguyen@sprintintl@sprint.com
  416. Mo Nikain                mo@bss.com
  417. Tom Nisbet               nisbet@tt.com
  418. Bill Norton              wbn@merit.edu
  419.  
  420.                                    7
  421.  
  422.  
  423.  
  424.  
  425.  
  426. Steven Onishi            sonishi@wellfleet.com
  427. David Perkins            dperkins@synoptics.com
  428. Carl Powell              cpowell@bbn.com
  429. Ilan Raab                iraab@synoptics.com
  430. Richard Ramos            ramos@mtunm.att.com
  431. Venkat Rangan            venkat@geoduck.matrix.com
  432. Louise Reingold          l.reingold@sprint.sprint.com
  433. Sam Roberts              sroberts@farallon.com
  434. Kary Robertson           kr@concord.com
  435. Dan Romascanu            dan@lannet.com
  436. Marshall Rose            mrose@dbc.mtview.ca.us
  437. Shawn Routhier           sar@epilogue.com
  438. Chris Rozman             chrisr@usr.com
  439. Assaf Rubissa            asaf@fibhaifa.com
  440. Jon Saperia              saperia@tcpjon.ogo.dec.com
  441. Michael Sapich           sapich@conware.de
  442. Michael Scanlon          scanlon@interlan.com
  443. Sam Schaen               schaen@mitre.org
  444. John Seligson            johns@ultra.com
  445. Paul Serice              serice@cos.com
  446. Chris Shaw               cshaw@banyan.com
  447. Timon Sloane             timon@rahul.net
  448. Robert Snyder            snyder@cisco.com
  449. Joo Young Song           jysong@ring.kotel.co.kr
  450. Roy Spitzer              roy.spitzer@sprint.com
  451. Einar Stefferud          stef@nma.com
  452. John Stephens            john@cayman.com
  453. Bob Stewart              rlstewart@eng.xyplex.com
  454. Kaj Tesink               kaj@cc.bellcore.com
  455. Dean Throop              throop@dg-rtp.dg.com
  456. Ahmet Tuncay             atuncay@synoptics.com
  457. Warren Vik               wmv@i88.isc.com
  458. Ioannis Viniotis         candice@ececho.ncsu.edu
  459. Steven Waldbusser        waldbusser@andrew.cmu.edu
  460. Alice Wang               alice.wang@eng.sun.com
  461. James Watt               james@newbridge.com
  462. Luanne Waul              luanne@wwtc.timeplex.com
  463. Gerry White              gerry@lancity.com
  464. Peter Wilson             peter_wilson@3com.com
  465. Steven Wong              wong@took.enet.dec.com
  466. Randall Worzella         worzella@ralvm29.unet.ibm.com
  467. Daniel Woycke            woycke@smiley.mitre.org
  468. Honda Wu                 honda@nat.com
  469. Jeff Yarnell             jeffya@protools.com
  470. Kiho Yum                 kxy@nsd.3com.com
  471.  
  472.  
  473.  
  474.                                    8
  475.